home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Tech Arsenal 1
/
Tech Arsenal (Arsenal Computer).ISO
/
tek-12
/
vir04002.zip
/
VIR04002.TXT
< prev
Wrap
Text File
|
1991-01-03
|
28KB
|
640 lines
From wang!elf.wang.com!ibm1.cc.lehigh.edu!virus-l Wed Jan 2 21:58:47 1991 remote from tosspot
Received: by tosspot (1.63/waf)
via UUCP; Thu, 03 Jan 91 08:07:18 EST
for lee
Received: from somewhere by elf.wang.com id aa29693; Wed, 2 Jan 91 21:58:46 GMT
Received: from IBM1.CC.Lehigh.EDU by uunet.UU.NET (5.61/1.14) with SMTP
id AA01551; Wed, 2 Jan 91 14:17:59 -0500
Message-Id: <9101021917.AA01551@uunet.UU.NET>
Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 7379; Wed, 02 Jan 91 14:14:19 EST
Received: from LEHIIBM1.BITNET by LEHIIBM1.BITNET (Mailer R2.05) with BSMTP id
7553; Wed, 02 Jan 91 14:13:59 EST
Date: Wed, 2 Jan 91 14:08:55 EST
Reply-To: VIRUS-L@ibm1.cc.lehigh.edu
Sender: Virus Discussion List <VIRUS-L@lehiibm1.bitnet>
From: "The Moderator Kenneth R. van Wyk" <krvw@cert.sei.cmu.edu>
Subject: VIRUS-L Digest V4 #2
Comments: To: VIRUS-L@IBM1.CC.LEHIGH.EDU
To: Multiple recipients of list VIRUS-L <VIRUS-L%LEHIIBM1@uunet.uu.net>
VIRUS-L Digest Wednesday, 2 Jan 1991 Volume 4 : Issue 2
Today's Topics:
VIRUS-L administrivia
Various Comments
Re: Job Market (PC)
Antiviral evaluation guidelines
FPROT review (PC)
VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed. Contributions should be relevant, concise,
polite, etc. Please sign submissions with your real name. Send
contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list. Administrative mail (comments, suggestions,
and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU.
Ken van Wyk
---------------------------------------------------------------------------
Date: Wed, 02 Jan 91 08:57:35 -0500
From: Kenneth R. van Wyk <krvw@cert.sei.cmu.edu>
Subject: VIRUS-L administrivia
Happy New Year everyone! In case you haven't noticed already, we're
now up to VIRUS-L volume number 4. I've updated the archives on
cert.sei.cmu.edu to reflect this. The pub/virus-l/archives/1990
directory now contains the entire volume 3 set, and there's a new
directory for 1991 (volume 4).
I hope everyone had a pleasant holiday season. I kept myself busy
downstairs in my brewery (read: basement). :-P Any other homebrewers
out there?
Cheers,
Ken
------------------------------
Date: 23 December, 1990
From: Padgett Peterson <padgett%tccslr.dnet@uvs1.orl.mmc.com>
Subject: Various Comments
Note: Thanks to flakey routing have missed posts 194-203. Apolgise
for not responding to comments in the interim. Happy Christmas.
>From: jmolini@nasamail.nasa.gov (James E. Molini)
>From what I have seen over the years, anyone who ever loaded a key
>into a piece of crypto gear has called themselves a Computer Security
>Expert at one time or another...
>So what does it take to be competitive in this field? It takes at
>least a bachelor's degree in Computer Science and a strong background
>generally in security.
Am reminded of the quip attributed to Mozart about what it took to
write an opera. When given an answer that would require the better
part of thiry years, the inquirer said "But Herr Mozart, you wrote
your first opera at sixteen." to which the composer replied, "Ah yes,
but I did not have to ask."
Having cut many a KG-13/KY-26 card & possessing an ME degree (from
GMI), this would place me in the first category, however, I did not
ask anyone (besides, who could you ask in 1966 ?) & feel there is a
point that needs to be made. At present, there are really two
different computer security fields: the first which Mr. Molini appears
to address is the traditional multi-user mainframe which has access
control as its primary requirement and provides insulation between
users and applications. In most cases the user has neither concern nor
care where WordPerfect resides, the system managers take care of this.
PCs are another story altogether.
Here there is no access control or partitioning other than a pseudo
one. The user and any application called can do anything it/he/she
wants. There is no RACF or CA/Top Secret and no user/kernel
separation. Since mainframe manufacturers make the innards of the O/S
a secret from the general public, often just a good knowlege of the
package in use is all that is necessary. (Though RACF is the only
security system I know of that will tell you where its holes are and
not trigger a violation for asking.)
To de-virus a PC (not just using CLEAN), the technician must
understand the iapx80X86 machine code at hex and assembly language,
operation of the BIOS, and the steps of loading a PC. Obviously the
writers of JOSHI had some coaching on this as the first level mistakes
are not made. These are entirely different skills than are generally
needed on a mainframe. I know of few places outside of defense
contractors where computer architecturists are still being utilized
(and to anyone who has ever been stuck with making a
Mil-Std-1750A/Jovial system work, my condolences but you probably have
the right skills.)
The biggest difference even with a unix environment is that in the PC
(and the MAC) environment things happen at such a low level that
little information is available (other than in fifty or sixty feet of
books at BookStop) and few bother to read it (did my bibliogaphy of a
few issues ago get posted ?)
Just for an example, many readers of Virus-L use VAXes (my favorite
PC) but how many know CHME, CHMK, & CHMS ? Its just not necessary
unlike REPNZ MOVSW or LODSB/STOSB that should throw up warning flags
to an observer in a PC.
The point is that these are just not skills that are taught anywhere
that I know of (possibly, I'll be pleasently surprised as when several
people reported that Logic is still taught in a few institutions)
>I have to read Virus-L at home because I
>have a "real" computer security job to go to every morning. I am not
>alone in this respect. Most companies don't realize the amount of
>"phantom dollars" they are spending on viruses today. When they do,
>we'll see a much more effective response to this problem.
Exactly ! Perhaps the problem is that management expects miracles
because we keep delivering them. In any event, I expect that nothing
much will happen until the lawyers get into the act with some massive
"negligence" suits from either stockholders of attacked companies or
customers who suffer loss. The the Snake-Oil salesmen will really
decend upon us.
Enough,
Padgett
These opinions are free and worth what you paid for them.
------------------------------
Date: 24 Dec 90 11:05:18 +0000
From: frisk@rhi.hi.is (Fridrik Skulason)
Subject: Re: Job Market (PC)
DRAGON@RCN.BITNET writes:
>... What kind of job market is there for computer programmers who
>specialize on detecting and eliminating viruses from other systems?
>Is it a job that one can make a decent living at? What languages
>(Computer) are best suited for combatting viruses? And who
>(Corporations) would hire a computer anti-hacker? Thanks for all
>your help.
Well...as I am one of the people who partially make a living out of
fighting viruses, I have a few suggestions.
You can indeed make a decent living by fighting viruses, but it is hard to
get rich. Anyhow, there are three options:
1 - writing and selling anti-virus software...it is possible, but
not easy...I just barely make enough money from my own programs
to continue writing them. If you want to write such programs,
be warned...it is a difficult market and crowded...but if you
still want to try...here is what you need:
Very good knowledge of assembly language...I am not talking
about a one-semester course or anything like that...you need
the kind of practice you get by writing assembly-language programs
for several years.
Very good knowledge of the operating system in question - you
must know every documented call, and also quite a few of the
undocumented ones.
Very good knowledge of the hardware...I/O ports, absolute
addresses etc.
Decent knowledge of at lest one high level language...C or
Pascal recommended.
Last, but not least...samples of most of the different viruses,
just to make sure your programs work. On a PC this means nearly
350 different viruses...and a lot of work...
The problem of course is to sell your program...having the best
anti-virus program is not of much use, if nobody knows of
its existence.
2 - Anti virus service...no programming, you just help people clean
up viruses and recover from attacks. This also involves
installing anti-virus programs.
3 - Writing about viruses...write a book...or magazine articles or
anything.
The problem, in my opinion, is that all the virus-books available
only increase the "popularity" of viruses, leading to the writing
of still more viruses.
- -frisk
Fridrik Skulason University of Iceland |
Technical Editor of the Virus Bulletin (UK) | Reserved for future expansion
E-Mail: frisk@rhi.hi.is Fax: 354-1-28801 |
------------------------------
Date: Sun, 23 Dec 90 00:06:04 -0800
From: Robert Slade <USERQBPP@SFU.BITNET>
Subject: Antiviral evaluation guidelines
Attached herewith is an article outlining the different classes of
anti-viral software, and features to check for in each class. This is
meant as an introduction to the anti-viral product reviews, which will
be coming out every few weeks for the next little while. (The first
review should be included in this same issue of the digest. It is
for FPROT.)
[Ed. A wholehearted thanks for the effort, Robert! I normally just
place articles of this length into the archives with a pointer to them
in the digests, but I'm making an exception in this case. In
addition, I'm placing this and any other reviews in the archives, on
cert.sei.cmu.edu in pub/virus-l/docs/reviews.]
Reviewing Anti-virus Products
Robert Michael Slade
3118 Baird Road
North Vancouver, B. C.
V7K 2G6
(604) 988-4097
I am quite certain that the first question to do with "anti-
viral" or other data security packages will be "which one is
best?" This ignores two vitally important points. The first is
that "the best" may not be good enough by itself. No security
force would ever pick "the best" guard, and then leave him to
guard an entire refinery by himself.
The second point is that, even within the limited realm of anti-
viral programs, data security software operates in many different
ways. Thus, one type of security may be better in one situation,
while another variety may be better in a different environment.
(Which make better guards, dogs or men? Wise security firms use
both.) There are basically five "classes" of anti-viral
packages; vaccines, change detection software, operation
restricting software, encrypting software and scanners. Each
type has it's own strengths and weaknesses.
Vaccine
Vaccine software is memory resident and watches for "suspicious"
activity. It may, for example, check for any calls to "format" a
disk while a program other than the operating system is "in
control". It may be more sophisticated, and check for any
program that attempts to alter or delete a program file.
It is, however, very hard to tell the difference between a word
processor updating a file and a virus infecting a file. Vaccine
programs may be more trouble than they are worth by continually
asking for confirmation of valid activities. They also may be
bypassed by viri that do "low level" programming rather than
using the standard operating system "calls".
It is very difficult to specify, in advance, what you should
check for in vaccine software, since the developers are loath to
state, in specific detail, exactly what the vaccine will be
checking for. (This reluctance is understandable: if a vaccine
developer "advertises" exactly what the product checks for, virus
or "trojan" writers will simply use another route.) Vaccine
software should be thoroughly tested in a "real" working
environment (one that uses all the programs you normally do, in
the ways you normally use them) for some time in order to ensure
that the vaccine does not conflict with "normal" operation.
Change detection software
Change detection software examines system and/or program files
and configuration, stores the information, and compares it
against the actual configuration at a later time. Most of these
programs perform a "checksum" or "cyclic redundancy check" (CRC)
that will detect changes to a file even if the length is
unchanged.
The disadvantages of this system are 1) it provides no
protection, but only notification after the fact, 2) some change
detection software is limited to operating system software only,
3) you must "inform" the software of any changes you make in the
system and 4) change detection software may not "see" changes
made by "stealth" viri. Some versions of this software run only
at "boot time", others check each program as it is run. Some of
these programs attach a small piece of code to the programs they
are "protecting", and this may cause programs which have their
own change detection features to fail.
A major factor in judging change detection systems is that of
installation and operation time. Since the system will be
calculating "signatures" of all (or all selected) programs on
your system (sometimes with very sophisticated algorithms), it
may take some time to install, and to "re-install" each time you
make a change to your system. It may also take an unacceptable
amount of time to check out a program before it will allow it to
run.
You should also find out how and where the security system will
"store" the necessary program signatures, particularly if you run
programs from diskette. Also, since these types of systems are
heavily influenced by the mini- and mainframe data security
community, it is important to query whether they have made
provisions for checking for boot sector viri, or other viri that
may not show up as changes to program files.
Operation restricting software
Operation restricting software is similar to vaccine software,
except that instead of watching for suspicious activities it
"automatically" prevents them. As with mainframe security
"permission" systems, some of these packages allow you to
restrict the activities that programs can perform, sometimes on a
"file by file" basis.
However, the more options these programs allow, the more time
they will take to set up. Again, the program must be modified
each time you make a valid change to the system, and, as with
vaccine programs, some viri may be able to evade the protection
by using low level programming.
It is important, with this software, that the operator is given
the option of "allowing" an operation. It is also important that
the operator be informed, not only that a particular program or
operation should be halted, but also why. There should not be
too many "false alarms" generated by the software, and it would
be helpful to have the option of "tuning" the software to be
less, or more, sensitive to a given type of activity.
Encrypting software
Encrypting software writes programs and/or data onto your disks
in a non-standard way and then "decrypts" the program or file
when you need to use it. This means that if a virus does try to
infect the system, it usually only scrambles the data and is
easily detectable. Used in conjunction with operation
restricting software features, encrypting software essentially
changes the whole operating environment, hopefully to one that a
virus cannot survive in.
Again, there is the need to do a lot of work in setting up the
protection system, and keeping it up to date when you make
changes. (It is also possible, if the system is not configured
properly to begin with, to end up with a system that you cannot
use and cannot repair.) There are two major "holes" in the
security of the system, 1) some part of the system must remain
"unencrypted" and is therefore vulnerable to "attack" and 2) if
you start with already infected files, the system will quite
happily encrypt the virus and allow it to operate.
One vitally important feature to consider in encrypting software,
particularly if it is coupled with operation restricting
software, is the ability to recover if anything goes wrong. Do
you have a recoverable backup, or are all your backup files
encrypted, and useless without the proper code? Can you boot off
a floppy to recover if your "security" program dies? If you can
boot off a floppy, what provisions guard against boot sector
viri?
Scanners
Scanning software is, paradoxically, the least protective and
most useful of anti-viral software. These programs examine
files, boot sectors and/or memory for evidence of viral
infection. They generally look for viral "signatures", sections
of program code that are known to be in specific viri but not in
most other programs. Because of this, scanning software will
only detect "known" viri, and must be updated regularly. Some
scanning software has "resident" versions that check each file as
it is run, but most require that you run the software "manually".
It is also the classic case of "bolting the door after the horse
is gone" since "scanners" only find infections after they occur.
Why then, with all the disadvantages of scanning software, are
they the most successful of anti-viral packages? Generally
speaking, it is because they force the user to pay attention to
the system. Again, when a user relies on one particular method
of protection they are most vulnerable.
Scanning software should be able to identify the largest possible
number of viri, and should be able to identify variations on the
more important sections of code (that is, it should be able to
"accept" the removal of text strings and other simple
modifications that "bush league hackers" might make.) For ease
and speed of updating, the "signatures" should be stored in a
separate file and there should be a source for the addition of
new viral signatures to the file. For security, both scanning
software program and signature files should be renameable.
Areas scanned should include not only the identifiable program
files, but all files, if necessary. Scanners should have the
ability to search the more common archiving formats as well,
particularly those that support "self extraction" functions.
Disk boot sector and hard disk partition boot records should be
scanned, as well (in this day of stealth viri) as memory.
copyright 1990 Robert M. Slade
------------------------------
Date: Sun, 23 Dec 90 00:11:24 -0800
From: Robert Slade <USERQBPP@SFU.BITNET>
Subject: FPROT review (PC)
Antiviral Protection Comparison Review
Company and product:
Fridrik Skulason
Box 7180
IS-127 Reykjavik
Iceland
frisk@rhi.hi.is
F-PROT-Virus detection/protection/disinfection and utilities
Summary:
Highly recommended for any situation. Best "value for cost" of
any package reviewed to date. Installation may require knowledge
of MS-DOS.
Cost
Site license
Education $1(US) per computer (minimum $20)
Other $2(US) per computer
Rating (1-4, 1 = poor, 4 = very good)
"Friendliness"
Installation 2
Ease of use 3
Help systems 2
Compatibility 4
Company
Stability 2
Support 3
Documentation 2
Hardware required 4
Performance 3
Availability 3
Local Support ?
General Description:
Of the five classes of anti-viral systems, the only one that
FPROT does not provide for is encryption. It provides vaccine
(F-LOCK), change detection (F-OSCHK, F-XLOCK), operation
restricting (F-DLOCK, F-XCHK) and scanning (F-DRIVER.SYS, F-FCHK,
F-DISINF, F-SYSCHK) protection. The package also includes
various system information utilities
Comparison of features and specifications
User Friendliness
Installation
The installation of FPROT is not a one step process, since the
package contains a number of different programs for different
protective purposes. The user must decide which programs to use,
and therefore the installation must be done in stages.
There is no installation program, but the documentation does have
a separate installation file. This file states that the user
should have a knowledge of MS-DOS, and that is likely necessary.
The installation process, however, is described clearly, and is
quite complete.
The package is distributed as "shareware", and therefore any user
who obtains it is likely to have the necessary skills for its
installation.
The installation procedure does "allow" one possible point of
infection if the computer is infected when the program is
installed, but the program will immediately detect the infection
unless it is not found in the signature file. Since the program
is "posted" in archived format, the user should be able to clear
the infection and start with fresh files.
Ease of use
All the functions of FPROT are found in different programs, and
all are invoked from the command line, so when a user knows what
function is desired it is a simple matter to obtain it. Only two
of the programs have any "switches" other than file or path
specification.
Help systems
As all packages are invoked from the command line for a single
function, there is no need for "online" help. When programs are
called without necessary file or path specifications, a message
explaining what is needed appears.
Compatibility
The various programs have been tested on a wide variety of
computers, and have not created any problems with hardware, even
on systems that have serious problems with TSR programs.
The documentation lists a number of "contra-indicated" software
packages and systems which may conflict with program operations.
However, in six months of testing, no normal character based
program or TSR has been found to conflict with any FPROT program.
Company Stability
Unfortunately, the future of FPROT is currently in doubt. It may
continue as a shareware product, or it may be sold to commercial
interests.
Company Support
No problems have been encountered with the program so far.
Fridrik Skulason is available through the Internet, and replies
to queries can be expected within a week or less.
Documentation
Being shareware, the package has no printed documentation. The
text files included with the programs are very clear and
thorough, and provide an excellent primer on virus functions and
protection. Novice users may, however, find the USAGE.TXT
document to be daunting. Fortunately only the INSTALL.TXT
document is required to use the product. The virus listings are
comprehensive as to the number of viri, if somewhat less
technical and detailed than the Brunnstein and Hoffman listings.
Hardware Requirements
No special hardware is required.
Performance
During testing, FPROT has consistently identified more viri than
the "current release" of any other product. It has occasionally
given a "false positive", but only in the case of identifying a
definite virus with two different names, or when scanning another
virus scanning product. FPROT is generally slower at scanning,
and the separate signature file renders it slower still, but the
separate file also allows new signatures to be added without
waiting for a product upgrade.
The user is in control of FPROT at all times, with the exception
that F-DRIVER.SYS will not allow the boot sequence to continue in
the case of a boot sector infection at startup.
FPROT, in six months of testing, has not given a false positive
alarm on any normal program, nor has it interfered with any
normal program operation.
Local Support
Since FPROT is shareware, there are no local dealers to obtain
support from. FPROT has fewer users in North America than SCAN,
and so local help may be harder to obtain, but the documentation
should make up any deficiencies.
For users in Europe, FPROT is available as a commercially
distributed product. For those in Canada, some support is
available through the new SUZY Information Service, through
INtegrity, the data security and anti-viral IN (Information
Network.)
Support Requirements
In a situation where technical support is available for the user
base, installation may best be performed by the support group. A
corporate environment will likely wish to have security policies,
and support for the package in addition to installation would
best be coordinated by this group.
General Notes
Because of its "shareware" distribution, FPROT is best compared
against John McAfee's SCAN program.
FPROT is definitely the more complex package, but that is because
of far greater functionality. SCAN, in it's most recent
releases, has offered a minor disinfection feature, but for most
disinfection one must obtain, separately and at separate cost,
the CLEAN and/or the older M-DISK programs. Resident
"vaccination" is also available, but again it is in the separate
SENTRY or VSHIELD programs. Finally, for use of any of these on
a network, NETSCAN is required. None of the SCAN family of
programs offers the system information utilities that FPROT comes
bundled with.
FPROT is kept up to date with regular additions to the signature
file, and constant improvements to the program. SCAN versions
are released at approximately the same frequency as FPROT, but in
a six month trial period from June to November of 1990, FPROT
releases consistently identified more viri, and with greater
accuracy than did the "same level" releases of SCAN. (During
this period, McAfee had to release four "bug fix" versions,
Skulason only one.) Fridrik Skulason also publishes the
signatures of new viri on the VIRUS-L (Usenet comp.virus)
distribution lists, and signature files can be updated between
releases.
FPROT, distributed as shareware, is free for individual users.
For a $15 US fee, Fridrik Skulason will mail out a "registered"
copy. The cost of the SCAN program is apparently subject to
negotiation, but the "list price" in the documentation,
shareware, for home use, is $25 US. For the full set of four
programs (SCAN, CLEAN, SENTRY and VSHIELD, not including NETSCAN)
mailed on disk from McAfee Associates the cost is $119 US. Site
licenses for FPROT are available for $2 US per CPU, $1 for
educational institutions. Site licenses for SCAN alone are
quoted at $8 US per CPU.
copyright 1990 Robert M. Slade
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 2]
****************************************